HTTP/3 (QUIC) foundation: Phase 6 (Stream layer and flow control) - #27882

Summary

Phase 6 of HTTP/3/QUIC support (#27675): the stream layer and flow
control, continuing from the completed Phase 5 work in #27881 (full
handshake completion). Builds on the completed Phase 0-5 foundation —
#27680, #27877, #27880, #27881 — all merged, and targets master directly.

See vlib/net/quic/PROGRESS.md
for the exact phase-by-phase checklist.

Scope

• frame.v extended with every stream-related frame: STREAM, RESET_STREAM,
  STOP_SENDING, MAX_DATA, MAX_STREAM_DATA, MAX_STREAMS, DATA_BLOCKED,
  STREAM_DATA_BLOCKED, STREAMS_BLOCKED.
• stream.v — QuicStream, stream ID categories (RFC 9000 §2.1:
  client/server-initiated, bidirectional/unidirectional, encoded in the
  low 2 bits), independent send/receive state machines per bidi stream.
  Even this client-first phase must correctly receive server-initiated
  unidirectional streams from day one -- HTTP/3's control stream and
  QPACK encoder/decoder streams are all server-to-client uni streams,
  not deferrable to a later server-support phase.
• flow_control.v — connection- and stream-level windows enforced
  together (a frame within its own stream's window can still be blocked
  by the connection-level aggregate window and vice versa); three
  separate stream-level initial limits depending on who opened the stream
  and its directionality; auto-window-growth heuristic to avoid
  throughput stalls; RESET_STREAM's Final Size reconciled against
  previously-received offsets (FINAL_SIZE_ERROR on mismatch).
• stream_reassembly.v — per-stream offset-ordered reassembly, mirroring
  Phase 4's crypto_stream.v pattern but for STREAM frames' implicit-length-
  at-end-of-packet handling.

Test plan

• Stream-ID category derivation (all 4 combinations) -- both directions
  (id -> category and category -> first id).
• Peer-initiated uni-stream acceptance -- the plan's own explicitly
  named test, confirming a server-initiated uni stream has exactly a
  receive half and no send half from the client's perspective, plus
  exercised end-to-end in the integration test below.
• Connection-vs-stream window interplay -- both directions (a tight
  connection window blocking a send the stream window alone would
  allow, and vice versa).
• FINAL_SIZE_ERROR on conflicting final size -- covers a final size
  smaller than already-received data, a final size that later changes,
  a final size conflicting with an already-buffered out-of-order
  fragment, and data arriving after the final size that would exceed it.
• Multi-stream interleaved integration test -- three streams (client
  bidi, server-initiated uni, second client bidi), STREAM frames
  delivered genuinely interleaved and out of order, each independently
  reassembled while one connection-level window tracks the running
  total across all three.
• All new/modified code passing under ./vnew test <path> -- 28/28
  files in vlib/net/quic/.
• ./vnew fmt -w applied to all touched .v files.
• Branch rebased onto upstream/master (2026-08-07) now that HTTP/3 (QUIC) foundation: Phase 5 (Full handshake completion) #27881
  merged (also via squash) -- clean git rebase --onto, no test
  adaptation needed (unlike HTTP/3 (QUIC) foundation: Phase 5 (Full handshake completion) #27881's rebase, no upstream validation
  change broke this branch's own tests).

/vreview (full A-G pass, run once while writing this phase and again
after the rebase before push) found and fixed:

Before commit: QuicStream.send/recv were Optional VALUE fields, so
mutating the unwrapped copy via note_data()/note_size_known() looked
like in-place mutation but silently didn't persist unless the caller
remembered to reassign it back (s.recv = recv) -- a future caller could
easily miss this and get stale state/final_size while the underlying
data was still correct. Fixed by switching to nilable pointers (matching
Tls13ClientHandshake.verified_chain's established convention) before any
real caller could hit it, eliminating the bug class rather than
documenting the trap. Also fixed two mechanical V-compiler quirks along
the way: match on a repeated array-index expression (frames[N]) stops
reliably narrowing a sum type once it has enough variants -- affected two
pre-existing tests in frame_test.v/initial_exchange_test.v that had
worked fine with fewer variants -- and a pre-existing "frame type 0x08 is
unimplemented" test that became false once this phase implemented STREAM
frames at that exact value (retargeted to 0x1e/HANDSHAKE_DONE).

After the rebase, before push: 2 confirmed sibling-parity gaps, both
citations verified against the primary RFC 9000 text before fixing.
parse_stream_frame/encode_stream_frame were missing RFC 9000 §19.8's
"offset + length ≤ 2^62-1" bound -- identical to §19.6's CRYPTO-frame
requirement, which parse_crypto_frame/encode_crypto_frame already
correctly enforce in this same file. parse_max_streams_frame/
encode_max_streams_frame were missing RFC 9000 §4.6's 2^60 cap --
already correctly enforced (with its own boundary tests) on the
transport-parameter half of the identical requirement in
transport_parameters.v. Fixed both, 5 new regression tests. Also
documented (not changed, since it's plausibly a future Phase 9 caller's
responsibility): open_local_stream has no max_streams enforcement,
unlike its receive-side sibling get_or_create.

🧙 Built with WOZCODE